The present invention is directed to computer communications and in particular to gateways that mediate communications between processes that communicate in different network protocols.
A large installed base of computer equipment employs a communications protocol known as Systems Network Architecture ("SNA"), which specifies the manner in which a host computer, for example, will communicate over a network with a device such as a terminal. At the same time, the Transmission Control Protocol/Internet Protocol ("TCP/IP")has enabled many disparate systems to communicate with each other over a wide variety of physical communications media.
To enable customers to communicate with SNA-compliant systems but take advantage of the large number of TCP/IP links, communications-equipment manufacturers have built communications gateways that translate between the two protocols. FIG. 1 depicts a typical gateway environment.
A user located in a city remote from a host mainframe computer 12 employs his terminal equipment 14, possibly in the form of a personal computer and modem, to gain access to an applications program that runs on the host 12. For this purpose, the user employs an Internet path 16; i.e., it employs the TCP/IP communications protocol to establish a Telnet connection. The Telnet connection is well known to the Internet community and described in its Requests for Comments ("RFCs") 854, 860 and 862.
The client terminal 14 is of a type sometimes referred to as a TN3270 emulator. The "TN" refers to the Telnet connection, and the "3270" signifies that the connection's data payload, namely, lines of EBCDIC characters and display parameters, takes the form of a "3270 data stream," so called because its form is that employed by IBM terminals and devices referred to as "3270s." (Actually, not all "3270"-device names take the form 327x, but all such devices do use the 3270 data stream.)
Such communication requires a TN3270 server such as server 18. Although the host in which the target application is running sometimes performs the TN3270-server process, having it do so is usually considered too prodigal a use of mainframe cycles. So FIG. 1 includes a communications channel 20 between the host 12 and the TN3270 server 18 to indicate that the TN3270 server is embodied in separate hardware.
TCP/IP transmissions occur in IP datagrams that include the transmitting node's IP address and encapsulate TCP segments that include the transmitting process's port number. The client-terminal process's TCP port number is usually arbitrary, but a TN3270 emulator connects to a server at a specific combination of IP address and TCP port number from which the server infers that the client thereby connected wishes to use the Telnet protocol.
To forward the terminal's information to the host, the TN3270 server will have to engage in an SNA communications session with the host 12. A brief digression follows to review a few well-known SNA features of particular relevance to the present discussion.
Communications software in an SNA node performs for each of that node's end users, such as a remote user terminal and the host applications program with which the user terminal is to communicate, a respective process called a logical unit ("LU"). The LU manages the data flow between the associated user and an LU being performed for some other end user. Additionally, each node performs a further process, called a physical unit ("PU"), that manages that node equipment's LUs and presents their data to the channel 20. (For reasons not relevant to the present discussion, a given hardware node may actually have more than one PU, but little is lost by considering the special case in which each hardware node runs only a single PU process.) Finally, one of the network nodes performs a further process called a systems services control point ("SSCP"), whose responsibility is the SNA network's overall organization. (Actually, different parts of the network can be organized by SSCPs operating in different nodes, but it simplifies the discussion to consider a single-SSCP network.) The host's Virtual Telecommunication Access Method (VTAM) software customarily provides this capability.
Now, let us assume that the host's SSCP process has already performed various initial network-organization tasks, such as activating PU processes in each SNA node. For instance, we assume that the SSCP has already activated PUs in the TN3270 server 18 as well as in an SNA communications controller 22 and a cluster controller 24 with which it communicates by way of a communications link 26 dedicated to communications between SNA devices. The cluster controller 24's purpose is to encapsulate data streams from non-SNA equipment such as a terminal 26 or workstation 28 in SNA messages for communication over the SNA network and to extract data streams from SNA messages for forwarding to that equipment.
After the network has been initialized, link-level transmissions that support communication among SNA network-addressable units, i.e., among units such as the PUs, the LUs, and the SSCP, occurs in basic link units whose format FIG. 2's first row depicts. At the first row's level of detail, the illustrated link unit's RU field can be thought of as the payload of lower-level processes that use the outer fields for bit transmission through individual links, for data transmission and routing through paths consisting of those links, and for management of communications sessions between network-addressable units. In addition, certain bits of the RH field affect the RU field's interpretation.
Now, the manner in which a given network node's LU process can be initiated depends on the particular SNA network and its node's capabilities. But in many cases the peripheral-node LU cannot be activated unless that node's PU receives a request to do so from the SSCP by way of such a link unit. We assume that terminal 26 and workstation 28 were already attached when the SSCP did the initialization, so the SSCP immediately orders that respective LU processes be activated for those devices. In a scenario that we now discuss by reference to FIG. 3, we assume that the TN3270 client 14 is not initially attached to the server 18 but that the host 12 nonetheless begins operation by activating in the server an LU process that can represent a client when one does become attached.
To this end the host sends a link unit whose transmission FIG. 3's line A represents. In that link unit the RH field's contents indicate that the RU contains not end-user data but rather an SNA request of an unspecified type within a specified category of requests and responses, and a request-code-indicating part of the RU indicates that the resquest is of the type whose mnemonic in SNA literature is ACTLU. This type of request directs a PU to activate an LU, and its RU field further specifies a local address, which the SSCP thereby assigns to the LU being activated.
As is well known to those skilled in the art, there are many request messages that the SNA protocol requires the receiving network-addressable unit to acknowledge. According to the protocol, the acknowledging unit fulfills this requirement by sending back a message whose "request" code is the same as that of the request message to which it is responding but whose RH field identifies it as a response rather than a request. For that reason, the message-type-identifying part of the RU field is often called a request/response code instead of a request code. In FIG. 3's line B, the notation "+Rsp" represents the acknowledgment of the preceding message, the plus sign indicating that the request was processed in the normal manner. The ACTLU response includes a field that indicates whether the LU is enabled, and in this case that field states that the LU is disabled.
FIG. 3's line C represents the client 14's thereafter establishing a TCP/IP connection, and line D represents a "TN3270 negotiation," the conventional Telnet colloquy by which a TN3270 emulator and a TN3270 server arrive at ground rules for subsequent communication. Having established those ground rules, the TN3270 server must conduct a corresponding session with the host, so its PU sends the SSCP a "request" of the type known as "Notify" in SNA literature, and the SSCP acknowledges the request, as FIG. 3's lines G and H indicate. The Notify request's contents indicate that the LU is now available for a communications session, so the SSCP now considers it enabled and upon its request establishes a communications session between that LU and a host LU that supports communications with a host-resident application to which the client's user desires access. Line I represents the resultant LU--LU session, which contains a TN3270 data stream.
The client eventually finishes the session and disconnects, as line J indicates, and lines K and L represent a Notify request and resultant response by which the host is advised and acknowledges that the LU is disabled.
At some point a new user may want to use a new client 30 (FIG. 1) to obtain access to the host application. For that purpose, client 30 establishes a TCP/IP link and performs a TN3270 negotiation with the server 18, as lines O and P indicate. For communication with the applications-process LU, and the server may choose to use the same LU process and therefore employ a Notify request (line S) to advise the host that the LU is now available for a session, and the host issues a resultant response in acknowledgment, as line T indicates. As lines U-X indicate, the LU--LU session and subsequent disconnect and disablement proceed as before.
In many installations, it is important for billing or other management purposes to keep track of different clients' use of various applications. For this purpose, a host-computer management application may monitor the SSCP's operations and thereby assemble statistics of various clients' usage. In traditional, all-SNA systems, this does not require any interference with communications; the messages that the LUs send to initiate sessions with others identify the logical units involved. For instance, the cluster controller 24 performs an LU process for each of its attached peripherals, and a given LU's local address therefore identifies the terminal 24, workstation 26, or other device by which a user obtains access to the target application.
In the TN3270 context, though, identifying the LU is not enough. As was explained above, different clients can employ the same logical unit. So the management application would itself have to include a process for real-time detection of session termination and for thereupon initiating a session with the TN3270 server to ask it the identity of the client whose session had just been completed. Time-sharing operations that employ SNA networks have therefore tended to forgo the convenience of Internet-link usage when billing or other user-based accounting has been important.